fix: upgrade cipher-base to 1.0.5 (CVE-2025-9287) - #754

Closing in favor of a cleaner fix — cipher-base isn't required anywhere in our own code either. It's a transitive dep of browserify's crypto-browserify polyfill chain (crypto-browserify → create-hash/create-hmac → cipher-base), not something our runtime code calls into.

This PR's approach (adding cipher-base as a new direct dependency) does actually dedupe cleanly in this case, but it still clutters package.json with an unused package. Replacing with an overrides entry in a follow-up PR, which pins both this and the ejs CVE (#755) at the root without adding fake direct dependencies.

Makes sense, thanks for the context; agreed that an overrides entry is the cleaner fix since cypher-base isn't a real dependency of ours. Happy to close this in favour of #759/#755. Let me know if there's a preferred pattern for how the security bot should propose fixes for transitive deps going forward (e.g. always prefer overrides over adding a direct dependency) so future scans don't hit the same issue.

@anupamme Yes — prefer overrides over adding a direct dependency, with one caveat: verify the override actually closes the gap. The #755 ejs PR is the cautionary example — adding ejs as a direct dependency only bumped the top-level hoisted copy and left the real flagged copy nested under @codedungeon/utils/node_modules/ejs untouched, because npm couldn't dedupe across that package's pinned range. So the fix should be "add/update an overrides entry for : ," then re-run npm install and confirm via the lockfile that no vulnerable version of that package remains anywhere in the tree — not just at the top level.

Two other things worth adding to the bot's playbook:

1. Check reachability before proposing a fix, not just presence. Both fix: upgrade ejs to 3.1.7 (CVE-2022-29078) #755 and fix: upgrade cipher-base to 1.0.5 (CVE-2025-9287) #754 were flagged purely because a vulnerable version string existed somewhere in package-lock.json — neither package was actually require()'d anywhere in this repo's source. Still worth patching (cheap, correct hygiene), but the "likely exploitable" / "handles user-influenced input" language in both PR descriptions was inaccurate and should be softened to something like "present in dependency tree" unless the scanner can confirm an actual reachable code path.
2. When a package is entirely unused (nothing in the tree even depends on it — like cipher-base, which was dragged in by a package (browserify) we brought in at some point and then abandoned. Once we removed the dead browserify dependency dragging it in, the better fix is removing the orphaned root dependency, not patching the version. Worth having the bot check "is this in the tree because something needs it, or because a stale direct dependency is unused" before choosing overrides vs. removal.

This is great feedback; thank you for the detail, especially the #755 catch. That's a real gap: an override at the root doesn't help if a pinned nested range prevents dedup, so "add the override" can't be the last step. I'll update the process to:

Verify, don't assume — after adding/updating an overrides entry, re-run npm install and grep the resulting lockfile for the vulnerable version across all nested locations, not just top-level. No "fix" ships without that confirmation.
Reachability before severity language — drop "likely exploitable" / "handles user-influenced input" unless there's an actual traced code path to the vulnerable function. Default to "present in dependency tree, not confirmed reachable" otherwise.

Distinguish "needed but outdated" from "orphaned" — before proposing an override, check whether anything in the current tree still genuinely depends on the flagged package, or whether it's only there because of a stale/unused direct dependency (like the abandoned browserify pull for cipher-base). If it's the latter, the fix is removal, not patching.